The variety of interfaces provided by Helix QAC means that two main usage patterns are possible:
- Use on the desktop by a developer
- Use as part of an automated build-test-distribute workflow
Desktop usage allows rapid correction of problems by the developers, as the code is being written. It is good practice for developers to run an analysis before checking any code into the version control system, just as unit tests would normally be run. In most cases, the analysis can be run and results viewed directly from the developer’s IDE. QA·GUI can be used if a non-supported IDE is being used for development.
Server-side usage would normally be run as part of a Continuous Integration workflow, or an overnight build process. Complete automation is possible, as QA·CLI commands can be called from scripts, which in turn can be called from CI tools. There is also a Jenkins plug-in available. Ideally, the results of the server-side processing should be uploaded into a results portal such as Validate (or the legacy portal Dashboard) for further analysis and distribution, but Helix QAC also has reports that can be run directly from QA·CLI.
Server-side processing options are known, and typically fixed, which means the results from Helix QAC are reliable and therefore can be easily used in an audit trail by customers.
These two usage patterns work well together. The Desktop usage helps to minimize the number of issues that reach the server-side processing. Likewise, having these results available from the server means that Desktop processing can skip these options, making it quicker to run.